× RexxLA Home About RexxLA About Rexx Community Members Symposium

Contact Us

Melinda Varian's Report

REXX Symposium, May 1995

by Melinda Varian


I attended the Sixth International REXX Symposium, hosted by the Stanford Linear Accelerator Center.

One of the most hotly discussed topics of the Symposium was IBM's recent announcement that all REXX development will be moved from Endicott, New York, to Boeblingen, Germany, over the next few months. Apparently, none of the current developers will be moved. Having seen IBM do this to a number of other software products in the past, I am inclined to believe that (however talented the Boeblingen programmers being assigned to this project) we will see a period of 18-24 months during which REXX will make little forward progress. I am always appalled at how casually IBM squanders its intellectual capital.

However, lest one be inclined simply to shrug and say that IBM management will never learn, there was another announcement that astonished seasoned IBM-watchers: REXX Development will port the soon-to-be-completed Object REXX to LINUX, and the source code for that port will be made available on the Internet in the hope that others will use it as a basis for ports of Object REXX to other flavors of UNIX. Anyone who does such a port will be allowed to market it for a profit, with no royalties to IBM.

Object REXX was demonstrated repeatedly during the Symposium and has clearly progressed substantially since the last Symposium. It is now scheduled to become generally available as follows:

  • OS/2, 10/95
  • PowerPC, 9/95
  • MVS, 12/95
  • AIX, 1995
  • VM, 3/96
  • Windows, 1995
  • LINUX, 7/95

Although Symposium participants were quite enthusiastic about the current implementation, several expressed reservations about IBM's choice of VisualAge as the visual tool to be used with Object REXX (that being a rather pricey piece of software).

Attendance at the Symposium was about 130, double last year's number. As usual, many authors of REXX implementations were in attendance, including:

  • Mike Cowlishaw, the author of REXX,
  • Charles Daney, the author of Personal REXX for DOS and Windows (Quercus Systems, P.O. Box 2157, Saratoga, California 95070, (408) 867-REXX).
  • Ian Collier, author of REXX/imc (UNIX), and
  • Anders Christensen, author of Regina (UNIX).

(We were all delighted to see Ian's bound copy of his Oxford doctoral thesis and to hear that he would soon receive his degree.)

Others in attendance included representatives from the Workstation Group (Uni-REXX and Uni-XEDIT, http://www.wrkgrp.com/) and from SIMWARE (2 Gurdware Road, Ontario K2E 1A2, Canada), which has REXX implementations for Netware, Windows, and the Macintosh.

Among the first-time attendees were Les Koehler, of Advantis, whom Mike credits with being the first person outside the UK to write a REXX program, and Russ Williams, now retired from IBM, who wrote the widely-used REXXIFY program that converted ever so many EXEC Classic and EXEC2 programs to REXX.

The Symposium program began with two excellent REXX tutorial sessions by Chip Davis, of Aresti Systems, a member of the REXX ANSI Standard Committee. The examples Chip used in his tutorials are available on the Symposium diskette.

The program continued with the following sessions:

Mike Cowlishaw (IBM), "REXX 1995: The Growth of a Language"

(Back to Table of Contents; on to next session).

REXX began when Mike woke up in the middle of a night in March, 1979, and began thinking about the possibilities. One of his inspirations was Chris Stephenson's 1973 paper that introduced the concept of a single macro language for many applications.

One of Mike's primary goals was to design a language that would be easy for users to learn and to retain (in other words, a language designed for the benefit of the user, not the implementer). His earlier experience with designing a language used for teaching programming had taught him that people have a hard time learning "notation"; that is, whenever people must learn (by rote) that a certain symbol has been assigned some arbitrary meaning, they have difficulty, and they tend to forget what they have learned if they go for a while without using the language.

By 1979, CMS users were writing quite complicated programs in EXEC2, so that language's use of ampersand to denote keywords and variables had become offputting. One saw programs in which more than 50% of the tokens began with ampersands.

Mike discussed his ideas for a new scripting language with colleagues at Hursley and with other IBMers over IBM's VNET network, which then had 300 nodes in Europe and North America. He sent out the first language specification and began incorporating the feedback. He typically wrote and circulated the documentation for each new feature to get feedback on the desirability of the new function before doing the implementation. He also typically first wrote a few programs to exercise the new feature and see whether it was right.

The first implementation was distributed via VNET on May 21, 1979. "From then on, the good ideas came from the users." For example, David N. Smith, the father of VMSHARE, insisted upon being able to nest comments.

Concatenation with a blank may be the only truly unique feature of REXX, according to Mike.

By the end of the first year of work on REXX, he had spent 1,000 hours on it (nights and weekends -- during the day he was designing hardware) and had produced 10,000 lines of Assembler and 5,000 lines of documentation.

He lists the following as the mistakes in his design:

  • Comparisons should have been case-insensitive. If he had had the concept of strict and non-strict comparisons at the time he changed the comparisons to be case-sensitive, he would have made only the strict comparisons case-sensitive.

  • DO should have been split into DO...END and LOOP...END.

  • REXX has too much emphasis on the External Data Queue (originally the CMS stack), which has turned out to be difficult to port.

  • Parsing is something of a compromise, too complex for some users and not heavy-duty enough for others. It might have been wise to use regular expression matching.

He lists these factors as being particularly significant in the success of the language:

  • Deliberate minimizing of "boilerplate", punctuation, and notation.
  • Hardware independence
  • Robustness
  • Upgradeability (keywords reserved only in context)
  • String support (especially the blank operator)
  • Associative arrays (stems)
  • Decimal arithmetic

The development of REXX would not have been possible without the VNET network. The use of the network for rapid design evolution was almost an experiment, although not a deliberate one.

During the period of 1980 to 1984, there were 30 internal releases of REXX. The change of Args to Arg is estimated to have broken 2.5 million programs. Estimates of the internal costs of changing the name from REX to REXX (at the insistence of the lawyers) were about $1 million (for updating local documentation, etc.).

The first non-IBM implementation of REXX was Charles Daney's Personal REXX in 1985. There are now more than 25 REXX products available, and the number continues to grow rapidly. (In addition, there are about 70 REXX books, other than manuals, in print.) Mike is attempting to build a complete list of REXX implementations and books and would appreciate receiving updates and corrections to the list to be found in the REXX Web page, http://www2.hursley.ibm.com/rexx/.

His concluding points were:

  • REXX is a carefully designed, purpose-built scripting language.
  • REXX has experienced steady growth over 15 years, and that growth has become increasingly rapid in the past 2-3 years.
  • REXX is installed on 15-25 millions users' machines.
  • There are well over 2 million REXX programmers.
  • It couldn't have been done without other people.

(The usage numbers given here are very conservative and arrived at by the convergence of multiple approaches to calculating them. One indication is the number of copies of Mike's book The REXX Language that have been sold, which is 100,000.)

Tim Browne (IBM), "REXX: Launching the Next Generation"

(Back to Table of Contents; on to next session).

Browne is (for the time being) the IBM REXX Product Manager. He began his talk with assurances that all would be well with the move of REXX to Boeblingen and added that everything he said here today will apply even though his group will not be doing the work.

He defined the mission of REXX Development as being to:

  • Continue to support Classic REXX;
  • Continue to evolve Classic REXX into Object REXX; and
  • Make Object REXX pervasive.

In response to a question, Browne stated that IBM will make Classic REXX conform to the almost-completed ANSI standard, although no other development is planned for Classic REXX.

Boeblingen will have 30 people working on REXX, including development, marketing, planning, and information development.

His group will pick up some PowerPC work that is overflowing from Boca Raton. He stated that the reason for not instead moving the PPC work to Boeblingen was that Endicott already has some PPC expertise.

The Object REXX port to Windows will work on Windows 32S, NT, and 95.

The LINUX version will be distributed at no charge. The only requirement for people using it as the basis of a product is to acknowledge that it is derived from the IBM version. (It will not have a GNU-style license, as products based on it can be sold commercially.)

The Object REXX implementations for IBM platforms will not be separately priced, but will be bundled into the operating systems.

Dave Gomberg (Experimenta), "REXX in PC/DOS 7.0"

(Back to Table of Contents; on to next session).

Dave Gomberg, who is co-author of the first REXX book (Robert O'Hara and David Gomberg, Modern Programming Using REXX, second edition, Prentice-Hall, 1988), presented a brief overview of the REXX that IBM has added to PC/DOS in version 7.0 (and that IBM has described as being "the programming language of choice" for that system).

IBM's having introduced REXX into DOS is important as a sign of IBM's commitment to REXX. The REXX in DOS is essentially equivalent to the one in OS/2, but Dave finds that he misses some function from Charles Daney's Personal REXX and REXXLIB products.

One problem with the new REXX is that REXX programs by default have an extension of BAT, rather than CMD. This means that they cannot change the path, because so much of the environment, including the path, is refreshed when a BAT program exits.

IBM seems also not to be deriving the benefit it might have from having added REXX to DOS, as there is little documentation or other "marketing" of the new function. There is a REXX manual for DOS, but nobody in the room other than Mike had actually gotten hold of a copy of that manual.

Markus Pelt-Layman (Pelt Industries), "RexxAnne: Issues and Problems Writing REXX Compilers"

(Back to Table of Contents; on to next session).

Markus Pelt-Layman is a very active REXX enthusiast. He has a background in building computer operations automation software. His company is developing the RexxAnne compiler and development environment for Windows and markets the Enterprise REXX interpreter for Windows NT. (RexxAnne is not yet on the market.)

Before launching the RexxAnne project, Markus had a marketing survey done that concluded that Windows users don't know about REXX and, thus, would not be likely to buy RexxAnne. That and his enthusiasm for REXX led him to begin his INTER REXX newsletter and Info REXX, a multimedia compendium of information about REXX.

Info REXX and subscriptions to INTER REXX are available from:

  • Pelt Industries
    8027 North 41st Street
    Longmont, Colorado 80503-8843
    (800) 741-4322
    outside the USA: (303) 442-7700

Markus requested photos, film clips, and other REXX information, such as news of REXX products and publications, for use in Info REXX. He mentioned that the next issue of INTER REXX will have an article by Mike Baryla, of IBM Endicott, that does an excellent job of showing off Object REXX.

Pelt Industries has a REXX bulletin board, Rexx-R-Us, (303) 440-1351.

Les Cottrell and Bebo White (SLAC), "Writing WWW CGI Scripts in REXX"

(Back to Table of Contents; on to next session).

SLAC had the first Web server in the United States (September, 1991) and was the first IBM customer to have REXX (in the early Eighties), so it was not surprising to find that SLAC is leading the way in using REXX to build WWW Common Gateway Interface scripts. These two speakers have made the handouts from their very useful presentations available on the Web:

Most of their examples were of using Uni-REXX on a UNIX server, but mention was also made of using Rick Troth's WEBSHARE server for VM. (Since the Symposium, I have found it easy to port some of the SLAC CGI code for use on VM.) I found Cottrell's discussion of security considerations in writing CGI scripts in REXX to be particularly helpful. (Be very careful about using Interpret. ;-)

Rick McGuire (IBM), "Object REXX Up Close and Personal"

(Back to Table of Contents; on to next session).

Rick has worked in REXX Development in Endicott since March, 1982, when he became involved in integrating the internal version of REXX into VM/SP3. The Object REXX work was begun in 1988 by Simon Nash and was transferred to Endicott about two years ago.

Rick began by saying that Mike's philosophy with regard to enhancing REXX has always been to find a single general solution that not only solves the problem at hand but also enables other solutions. He makes a point of avoiding "creeping featurism". REXX Development has tried to adhere to that philosophy in writing Object REXX.

A beta-test version of Object REXX is available on the OS/2 Developers Connection. Object REXX is a complete rewrite of the interpreter. It is entirely upward compatible with "REXX Classic" and addresses many non-OO requirements against REXX Classic. The Object REXX interpreter is twenty percent faster than the existing Classic interpreter, as measured by Mike's standard REXX benchmark. (The design goal had been for no more than a fifteen percent degradation in performance.)

The remainder of Rick's presentation was an overview of Object REXX. Later in the symposium, another speaker commented that he had been disappointed to learn how much "notation" has been added to REXX for Object REXX, and I found myself agreeing with his comment. Nevertheless, Object REXX is an impressive achievement. The single hour allotted for Rick's presentation was far too little to allow him to do justice to the subject, and his pace was such that my notes below are very incomplete.

In Object REXX, everything is an object; everything that happens is a method; and everything that happens is caused by a message. It used to be in REXX that everything was a character string; now character strings are but one kind of object. Methods are actions on objects. Messages invoke methods. The character "~", which is pronounced "twiddle", sends a message. Thus, say name~word(2) is the same as say word(name,2). In the first case, the twiddle sends the message "word(2)" to the object "name" and thus invokes the "word" method of the "name" object, passing it an argument of "2". One can use either syntax as long as the objects are all strings.

(In addition to "~", there is also "~~". Both send a message, but while "~" returns the result of the method, "~~" returns the object that received the message.)

All REXX operators are now messages. Thus, say 1+2 is equivalent to say 1~'+'(2). The latter sends the message "'+'(2)" to the "1" object, invoking its "+" method with the argument "2". Most people would not want to code in that form, of course, but the benefit of making operators methods is that now one has "operator overload" or "polymorphism". The same message may be sent to dissimilar objects, and the specified method will behave as appropriate to the nature of the object in each case. For example, Object REXX has a Complex class which defines complex numbers. x = .complex~new(2,3) creates an instance of a complex number. (The message "new(2,3)" is sent to the "complex" class to invoke the class method "new" with arguments appropriate to a complex number.) After that statement is executed, say x produces "2+3i". Objects of the complex class have a "+" method. Thus, this little program:

  x = .complex~new(2,3)
  y = .complex~new(4.5,6.7)
  say x+y

displays "6.5+9.7i". say x+y could be replaced with say x~'+'(y), but that is too ugly for anybody to use.

(The leading dot denotes an environment symbol. Its default value is the string consisting of the characters of the symbol translated to upper case. If the symbol identifies an object that the current environment has defined, its value is that object. In the case above, ".complex" identifies the Complex class, which like other Object REXX classes is preloaded into the environment.)

Every class has a "string" method, which returns its string representation. Thus, if we create an instance of the Animal class by specifying pooh = .animal~new, then say pooh displays "an ANIMAL". Objects of the hypothetical Animal class might also have a "display" method that would display other properties of the objects; that is, pooh~display might produce "Animal of genus ... with name eating ". An ugly syntax could be invoked to set the name for the object (assuming "name=" were a method of the Animal class):

  pooh~'name='('Eeyore')

After that, pooh~display would display "Animal of genus ... with name Eeyore eating ". The same assignment could be done more attractively by pooh~name = 'Eeyore', and say pooh~name would produce "Eeyore".

Each class has a "methods" method that returns a list of methods for the class.

Directives, denoted by "::", split programs up into blocks to provide additional structure. (Control does not flow through a "::". Directives are processed first, and each denotes the termination of the previous block.)

There is a ::CLASS directive to define a class, e.g.:

  ::class complex public inherit stringlike

The ::METHOD directive denotes the beginning of a method. For example, the "init" method (used for building a new instantiation) of the Complex class might look like this:

  ::method init
  expose real imaginary
  use arg first, second
  real = first + 0
  if arg(2,'Omitted')
     then imaginary = 0
  else
     imaginary = second + 0

Use Arg has been added in Object REXX for passing objects as arguments; it provides essentially a call-by-reference capability. Expose is used to expose and create object variables within methods. It allows variables to be shared between methods and to persist between invocations of the same method.

To continue with the example above, an object of the Complex class would also have a "+" method that might begin like this:

  ::method '+'
  expose real imaginary
  use arg adder
  if arg(1,'Omitted')
     then return self
  ...

"self" is new in Object REXX. It is a special variable that is set when a method is started (unless it is exposed). It is the value of the object against which the method is running.

Subclassing allows the definition of new classes that inherit the behavior of a class and add additional class-specific behaviors. For example, one might define the "Dog" class as a subclass of the "Animal" class. Then after the statement lassie = .dog~new had been executed, lassie~display might produce "Animal of genus Canis with name..."

Multiple inheritance is supported. Objects (and classes) may inherit from more than one class. In addition to a single parent class, an object may inherit from zero or more "abstract" or "mix-in" classes.

The special variable "super" is another that is set when a method is started (unless exposed). Its value is the class object of the immediate superclass. Thus, self~init:super would invoke the "init" method of the superclass and might be part of the "init" method for the subclass.

::method sound attribute creates "sound" and "sound=" methods.

There is an "uninit" method that is driven when the object is going to be garbage-collected.

Rick also described the concurrency that is built into Object REXX. All objects can execute concurrently. Coordination is achieved via the "start" message and the reply instruction.

The implementation of concurrency is not dependent on an underlying thread model; they have it running on Windows.

Tom Brawn (IBM), "Object REXX OpenDoc Support"

(Back to Table of Contents; on to next session).

Tom spoke briefly on the alignment of Object REXX with OpenDoc, which is an architecture for dealing with compound documents. (It competes with Microsoft's OLE.) It was developed originally by Apple. IBM is doing implementations for OS/2, AIX, and the Power PC. Word Perfect is doing an implementation for Windows. One will be able to write REXX scripts for OpenDoc "scriptable applications", such as Lotus 1-2-3.

Rick McGuire (IBM), "Other Fun Stuff"

(Back to Table of Contents; on to next session).

Rick spoke briefly about using Object REXX to write "network agents" that can be sent across a network to play games on a server and that can be implemented with no knowledge of networking. Thus, one has the infrastructure to provide client/server applications without changing the code in existing programs. He has implemented a scripted Web explorer using these techniques.

Brian Marks (IBM), "Report from the X3J18 Committee"

(Back to Table of Contents; on to next session).

Brian is the chairman of the REXX ANSI Standard Committee, X3J18. The Committee completed its document in 1994; the first public review ended May 3, 1995. The document is expected to be approved as an ANSI standard this year. The Committee continues in existance both for maintenance purposes and for further versions, including Object REXX.

The document was edited by Tom Brawn. It is 167 pages (including the informal parts) and is available from the REXX Web page, http://www2.hursley.ibm.com/rexx/.

The second edition of "TRL" (Mike Cowlishaw's book The REXX Language) was the basis for the standard. Brian commented that this first standard was not intended "to design a REXX for the Nineties", but primarily to standardize the current language. However, it does add date conversion, error subcodes, and command I/O to the language.

  • Date and time conversion (i.e., as the existing DATE() and TIME() but for any date and time, not just the current ones): These have been on users' wishlists for a very long time and implementations were beginning to appear, so the Committee felt it would have been remiss not to provide a standard before differing implementations are promulgated.

  • Error subcodes: The original REXX implementation needed short error messages because of memory constraints that are no longer relevant. Thus, we have the dreaded "Error 40" (incorrect call to routine). With the error subcodes defined by the standard, the user will be told in the Error 40 case which function and which argument were in error and what the error was. "We may have gone a bit overboard."

  • Command I/O: The Committee found that various implementations were all issuing host commands, but there was no consistency in giving input to the commands or in capturing command output. The standard addresses this problem by extensions to the Address instruction. One solution uses stemmed variables. (This has given some legitimacy to the tradition of making stem.0 contain the count of items in the stem.)

Brian also stated that the standard was not meant "to be the union of every existing implementation", but some accommodation for the requirements of different operating systems was made, such as allowing alternatives for negation and blank characters. (They didn't make it the union of all implementations, because they didn't want to confuse new implementations.)

  • Negation: The preferred negation symbol is "\" (backslant), but others are allowed.

  • Blank: There is not "one true blank", i.e., they have made some allowance for tabs.

Although the Committee made few changes to the existing language, it did not take a position of "better wrong than changed". They have "righted existing wrongs", but few programs should break, and they expect implementations to have a non-ANSI switch. The relatively obscure wrongs that are being righted:

  • D2C(n,0) is the null string according to TRL, but some implementations do not follow that. (CMS does.)

  • DATATYPE('','B') "is wrong in TRL". A 0-length string is not binary, but a 0-length (after blank removal) hex string is hex. (CMS does not report the datatype of a null string to be binary; it does report it to be hex.)

  • DATATYPE(1.00000....00003,'W') has produced a value of TRUE in the past because of precision tests, but it is not an integer and will not be treated as one under the standard.

Brian concluded by encouraging the attendees to encourage their REXX vendors to produce implementations that comply with the standard.

Sandy Syx (Mantissa Corp.), "CenterPiece: An Object-Oriented REXX Development and Runtime Environment"

(Back to Table of Contents; on to next session).

CenterPiece wins my prize for being visually the handsomest product displayed at the Symposium. One seldom sees such subtle use of color in GUI applications.

Mantissa Corporation specializes in software to automate computer operations. It has developed its own multi-threaded, object-oriented REXX for use in building its software products. Since this OO REXX has been developed completely independently of the IBM OO REXX, it was interesting to contrast the two approaches. The speaker, Sandy Syx (ssyx@mantissa.com), provided such complete foils that I think the best way to report his talk is simply to transcribe his foils:

CenterPiece Architectural Overview

What is CenterPiece?

  • CenterPiece is a distributed, multi-platform, object-oriented, interpretive development and runtime environment.
  • Two main executables:
    1. The Engine -- a multi-threaded interpreter than serves objects to multiple simultaneous clients in pseudo realtime.
    2. The User Interface -- A graphical application that allows one to view and manipulate objects that exist in the engine.

CenterPiece Architecture

  • Persistent objects are stored on disk in object files.
  • Objects exist in the Automation Engine; all program interpretation occurs in the Engine.
  • Objects are viewed and manipulated in the User Interface.

CenterPiece is Multi-platform

  • Object files are platform independent.
  • The Engine supports multiple concurrent connections to user interfaces and can run on multiple platforms.
  • The User Interface is multi-platform, supporting multiple look-and-feels.

The Engine Is...

  • The heart of the system.
  • An object server.
  • A multi-threaded object-oriented REXX interpreter.
  • Basically event-driven.
  • Responsible for reading and writing object files.
  • Not visual.

The User Interface

  • Graphical User Interface.
  • Runs on multiple platforms and window systems (X-Motif, OS/2 Presentation Manager, MS Windows).
  • Supports multiple look-and-feels (Motif, CUA, Windows).
  • Very interactive, allowing direct manipulation (object menus and drag-and-drop).

CenterPiece Built-in Classes

Fundamental Built-in Classes

  • Workspace -- 2-1/2 dimensional visual container of Workspace Objects.
  • Workspace Object -- gives objects the ability to be on a workspace (name, X, Y, layer, icon, workspace, etc.).
  • Class -- allows one to create new classes.

Programmer's Helper Classes

  • Program -- allows interpretation and execution of REXX logic.
  • Thread -- instance of executing program.
  • List -- ordered collection of items.
  • Dictionary -- unordered collection of key/data pairs.
  • Semaphore -- resource arbiter.
  • Queue -- object version of REXX queue.

Simple Visual Objects

  • Text -- floating text (font, color, angle).
  • Line -- line segment (x2, y2, width, color).
  • Rectangle -- Hollow or filled rectangles (width, height, fill color).
  • Image -- 2D color images (can be large and deep).

Dialog Objects

  • Button -- action button that runs a "Click" method when pressed.
  • Checkbox -- state selector runs a "Click" method when pressed.
  • TextEntry -- text entry field, allows multi-line, scrollbars, etc. Runs a "Changed" method when text is entered.
  • ListBox -- combination of a List and a ListView. Visual list, allows images and text. Items can be dragged from the list.
  • Slider -- Allows a value to be selected within some range. Runs a "Slide" method when the slider is slid.
  • RadioGroup -- Mutually exclusive group. Runs a "Click" method when the selection changes.
  • Spinner -- Allows spinning or typing in a number from a specified range of values.

Communication Classes

  • MTAServer (MTA=Message Transport Agent) -- allows one to create a "server" that will listen for connections from "clients" at any number of access points (transport, port). Allows telneting into the server if TCP is used.
  • MTAClient -- Allows one to connect to a server to exchange messages.

Object Storage to Disk

  • ObjectFile -- Saves all owned objects to a disk file.

Application Delivery

  • UserProfile -- This class allows one to secure access to a CenterPiece engine by defining exactly who can connect and how they can connect. Users can be "Developers", "EndUsers", or both. An EndUser has a "Connect" method that can be overridden to show the appropriate application dialogs for the user on connection to an engine.

CenterPiece Object-Oriented Extensions to REXX

Objects

  • Objects are instances of some Class.
  • Objects have any number of attributes.
  • Objects are globally visible.
  • Every object has a universally unique immutable identifier.
  • Any object can be made persistent.

Object Ownership

  • Objects can own any number of other objects.
  • An object can have at most one owner.
  • When an object is destroyed, all of its owned objects are also destroyed.
  • When an object is saved, all of its owned objects are saved.

Attributes

  • Attributes act much like REXX variables.
  • They can be simple or compound.
  • Object attributes must be defined in some superior class.
  • Attribute names are case and space preserving, but case and space insensitive.

Referencing Objects

  • Objects have global visibility.
  • Each object is unique, not because of its name, class, nor attribute values, but because of its universally unique immutable identifier (UUID). These are normally just called "object-identifiers" or "object-ids".
  • Objects are referenced by REXX variables that have an object-id as their value.

Attribute Access

Object Attributes are selected with a double dot (..).

                         object..attribute
   object identifier or, <======|======> attribute specification
   classname

The symbol to the left of the double dot is translated into a value. The translated value must be an object-id or a class name.

The symbol to the right (up to the next double dot) is treated exactly like a variable symbol and must reference an object or class member.

Attribute Access Examples

  • Simple Attribute Access: Assume b is an object of the Button class.
         b..Name = "Press Me"
         b..BackgroundColor = "maroon"
    
  • Multiple Indirections: Assume that b is a Button, and assume that the button has an attribute "Workspace" that references an object of the Workspace class that the button is on. The name of the workspace could be accessed by:
         b..Workspace..Name
    

Object Creation/Destruction

Accomplished with two new REXX built-in functions:

     object_id = ObjectCreate()
     rc = ObjectDestroy()
For example,
     aLine = ObjectCreate( "Line" )
     aLine..x = 100
     aLine..y = 100
     aLine..x2 = 200
     aLine..y2 = 200
     ...
     call ObjectDestroy aLine

Classes

  • Classes define attributes that each instance of the class will have.
  • CenterPiece allows multiple inheritance.
  • Classes are objects and are instances of the "Class" class.
  • Classes are typically used by their name.

Inheritance Model

  • Attributes are inherited dynamically.
  • A class can be modified "on the fly" with existing instances.
  • Attribute lookup precedence:
    1. Local Object Override
    2. Objects's Class
    3. Primary Superclass--->Root Class
    4. Secondary Superclass--->Root Class
    In other words: "A Depth-first, breadth-next search up the class hierarchy".

Dropping Attributes

The REXX Drop instruction can be used to cause an attribute to revert to its class default.

For example, assume that a class "Author" exists which has an attribute named "Name" that has a class default of "anonymous".

   anAuthor = ObjectCreate( "Author" )
   anAuthor..Name = "Fred Brooks"
   say anAuthor..Name         ==> would print "Fred Brooks"
   drop anAuthor..Name
   say anAuthor..Name         ==> would print "anonymous"

Object-Related Built-in Functions

   ObjectCreate                   ObjectOpen
   ObjectDestroy                  ObjectOpenAsDialog
   ObjectClone                    ObjectClose
   ObjectFindOfClass              ObjectGoto
                                  ObjectGetOwner
   IsObject                       ObjectSetOwner
   IsObjectOfClass
   ClassOfObject                  ObjectFileOpen
   ClassIsSubclassOf              ObjectFileSave
   ClassIsDirectSubclassOf        ObjectFileClose

Iterating Over Objects

   DO   ; 
     END  ;

   repetitor (extensions):
     FOR EVERY class loopvariable
     FOR EVERY class loopvariable ON workspace
     FOR EVERY class loopvariable OWNED BY object

Example: Iterating Over All Objects of a Given Class

   num_employees = 0
   DO FOR EVERY Employee e
      SAY e..Name
      num_employees = num_employees + 1
   END

Object Member Iteration

   DO   ; 
     END  ;

   repetitor (extensions):
     FOR EVERY  MEMBER membervar
          OF object

Composite Objects

  • "An object by itself is intensely uninteresting". Grady Booch
  • Object Identifiers behave much like pointers to structures in C or C++.
  • Any object attribute can contain an object identifier of another object.
  • Composite objects can be made in which one object references and owns any number of other objects.

Embedded Objects

  • It is possible to embed objects within other objects.
  • This must be done by adding a class member that references an object of a specified class.
  • The embedded object will be cloned for each instance of the class.
  • The embedded object may not be destroyed independently of its owner.

Methods

  • Methods are simply objects of the Program class that are referenced by some attribute of an object.
  • Method invocation is no different than calling any other REXX function or subroutine. The method is addressed just like any other object attribute, except that it is used where a function or subroutine name would normally be used.

Self Reference in Methods

The double-dot with no prefix is an object self reference inside an object method. For example, imagine a user interface Button method that runs when the button is clicked:

     /* begin Button..Click */
        ..Name = "Hello"
     return 0

In this example, the double-dot with no prefix means "this" button.

REXX Extensions for Complex Problems

Multi-threaded REXX

  • An additional built-in function, Start(), is provided to allow one thread to start another.
  • Each thread executes concurrently.
  • Threads are re-dispatched, basically, after each source instruction.

Unwinding the Stack on a Raised Condition

Normal REXX, strangely, doesn't unwind the call stack when a condition (exception) is raised. We extend the CALL ON and SIGNAL ON instructions to allow them to be prefixed with the keyword UNWIND. For example:

     UNWIND CALL ON syntax NAME mysyntaxtrap
     . . .
     mysyntaxtrap:
        say "Tarfu"
     return

Developing CenterPiece Classes

Modularity

  • Instances do not have to be saved in the same ObjectFile as their classes.
  • Classes do not have to be saved in the same ObjectFile as their superclasses.

Constructors/Destructors

  • Any class can have a "Create" method. Simply add an attribute named Create and make it a sub-object that is of the Program class.
  • The method will automatically be run when an instance of the class is created.
  • Ditto for "Destroy" and "Load", which will be run when the object is destroyed or loaded from an ObjectFile, respectively.

User Events

  • Many classes have methods that are run in response to user actions.
  • These methods are optional, and if not provided, a default built-in action occurs in response to the user event.
  • Some examples are:
    • WorkspaceObject..Drop or Dropped Upon
    • Button..Click
    • TextEntry..Changed
  • The first argument to a user event method is always a Dictionary object that contains entries that indicate what happened.
  • The attributes present in the context dictionary depend on the event. For example, a Drop event would have the X and Y locations of the object dropped.
Mantissa Corporation
201 Summit Parkway
Birmingham, Alabama 35209
(205) 945-8930

John Tibbetts (Kinexis), "REXX, Distributed Systems, and Objects"

(Back to Table of Contents; on to next session).

Tibbetts addressed the current state of client/server technology and the reasons for the failure of so many client/server applications. I was reminded of the definition I'd heard recently of "second-generation client/server", i.e., "We'll do it right this time".

Tibbetts asserted that there is not an infrastructure on the planet that can implement an object-oriented, distributed, robust application, and that this is the reason why mainframe sales are way back up. He believes, however, that the necessary technology will be available quite soon. He also commented that most failures of "light-weight" client/server applications are due to a lack of understanding of the importance of function as an asset.

He divided the development of our industry into four phases:

The Four Phases of Computing

  1. Centralized computing (the mainframe)

  2. Clients to a Database Server
    • Power to the user
    • Power to the user interface
    • Uneven performance and integrity
    • A weak 3-tier architecture
    • Trust problems

    This is what PC Week means by "client/server". Microsoft is a heavily Phase2-oriented company.

    Phase 2 applications tend to fail when they go to multiple sites or when they need multiple trust levels. Scalable performance is a problem. To optimize a distributed application, the function should be as close to the data as possible; Phase 2 applications are the opposite of that. Their goal is accessibility, not security.

    PC-class machines are metaphysically agents of the individual, not of the enterprise; whereas a 3270 terminal sitting on one's desk is an agent of the enterprise.

    Phase 2 C/S applications can work fine for work groups; they have the same kind of agenda. They can also work fine for departments, but not for the enterprise. They are not like down-sized mainframe applications; they are like upgraded PC applications.

  3. Clients to a Function Server
    • Function is closer to the data
    • Improved performance and integrity
    • Stronger 3-tier architecture
    • Trust tuning
    • But significant software complexity (because split across platforms)

    This phase has fatter servers and skinnier clients. These C/S applications are bloody hard to build, but appropriate tools are beginning to come to the market.

  4. And Then There Are Objects
    • Inately partitioned
    • Semantic continuity
    • Limited transactional awareness

    The object is data surrounded by a protective layer of code. This may be viewed as a very fine-grained version of Phase 3; it has lots of small programs, but the interfaces are architected. This sort of C/S application is hard to do, because the infrastructure is profoundly function-oriented, rather than object-oriented. However, we will see the infrastructure for building high-integrity, robust application environments by the end of 1996.

Security and transactions never entered into the minds of the people who designed object technology. That function is now being added, and that is a big reason for not going to object technology too soon.

Acid Tests for Transactions

  1. Atomicity
    • Transactions all or nothing (integrity principle)
    • Wedding vows (two-phase commit)
  2. Consistency
    • Transactions are a correct transformation of state
    • debits = credits
  3. Isolation
    • Concurrent transactions behave as if executed serially
    • Transactions don't see other transactions' partial results
  4. Durability
    • Once committed, transactions are not forgotten
    • Bound to honor commitments

Most distributed object infrastructure today is not transaction-oriented. "I saw my first demonstration of OTS (Object Transaction Service) last week; this has Phase 4 transactional components."

Rick McGuire (IBM), "Getting Ready for Object REXX"

(Back to Table of Contents; on to next session).

Object REXX addresses many of the long-standing requirements against the REXX language, in addition to adding OO capability:

  • Object REXX supports date and time conversion in the general case.

  • The requirement to pass stems is addressed by use arg.

  • The requirement to return multiple values is addressed by the fact that a stem object can be assigned to a stem. That is, a.=x does not set the default value of items in the a. stem if x is a stem object; instead, it assigns one stem to the other.

  • Support is added for expressions in the tails of compound variables. In x.[x.0], the square brackets contain the variable part of the tail.

  • Support is added for traversing stems with do tail over stem.

  • The requirement to package multiple functions without creating a file for each function is addressed by the use of directives. The ::REQUIRES directive loads the specified program. ::ROUTINE marks the beginning of a new routine within a source file.

  • The requirement to share variables between programs (without explicitly passing them) is addressed by environment variables, which form essentially a global variable pool. (There is also a local environment that is local to a process.)

  • The requirement to be able to call a routine whose name is a variable is addressed very simply by call (name).

  • Object REXX has an Array class that will replace many uses of stems. The indices must be numeric. Do over traverses them in order. (Tables can be used for collections with non-numeric indices.)

  • Directories may also be useful in preference to stems for dealing with structured data. For example, employee.name can fail if name has been used as a variable, but this sequence is always safe:
         employee = .directory~new
         employee~name = 'Rick'
    

Simon Nash (IBM), "SOM: Present and Future"

(Back to Table of Contents; on to next session).

Simon is the original author of IBM's Object REXX, which he worked on for five years. He is now in SOM Development.

SOM, the System Object Model, is IBM's strategy for facilitating interoperability among OO languages. It defines interfaces that allow class libraries to be distributed in object form and to be used from languages other than the implementation language. This leads to release-to-release binary compatibility and the ability to distribute objects.

SOM is available today for OS/2, AIX, Windows, and Macintosh. It is announced for MVS and AS/400, and there are other ports in progress, including to other UNIX platforms. SOM support is available for C, C++, and Smalltalk. SOM support for Object REXX is in beta test. SOM support for OOCOBOL is announced.

Stephen Rondeau (AugmenTek), "Rexinda: A REXX Implementation of the Linda Parallel Programming Model"

(Back to Table of Contents; on to next session).

Rexinda is a REXX implementation of David Gelernter's Linda parallel programming model. (Gelernter named Linda for Linda Lovelace, as a play on Ada's having been named for Ada Lovelace; he is said now to regret this.)

Rexinda implements a Linda "tuple space" and REXX functions to put tuples into the tuple space, take them out, wait for a tuple to appear, etc. A tuple can be thought of as a database record. The tuple space is an unordered collection of tuples, possibly distributed over many processors. Thus, the tuple space provides an associative global data area for sharing of data at the record level among multiple processes. The ability to wait for the appearance of a tuple makes it simple for parallel programs to coordinate their progress.

Retrieving a tuple is done by matching on its contents by value, number of fields, datatype, etc. Updating a tuple is an atomic operation. An EVAL() function allows a Rexinda program to start a new process, which may then also access the tuple space.

Rondeau hopes that a REXX implementation of Linda will help popularize parallel programming, particularly because of the fast prototyping capability provided by REXX. His implementation manages not to require preparsing of the source. It does data-typing automatically, but allows for overrides. One of the interesting requirements was to make REXX handle user-defined events (i.e., data appearing in the tuple space).

He sees a good many parallels between the Linda model and REXX. Linda's associativity should be simple for REXX programmers to understand, being not very different from the way compound variables work in REXX. The tuple space is global, like the default scope in REXX.

Version 0.1 of Rexinda is available now for OS/2 and Amiga. Rondeau has plans for extensive enhancements, if there is sufficient market acceptance. Inquiries may be addressed to:

  • AugmenTek
    3606 South 180th Street C-22
    SeaTac, Washington 98188
    (206) 246-6077
    augmentek@acm.org

For more on the Linda programming model, Rondeau suggested How to Write Parallel Programs by Carriero and Gelernter (MIT Press, 1991, ISBN 0-262-03171-X).

Bob Vogel (IBM), "REXX for CICS/ESA"

(Back to Table of Contents; on to next session).

Vogel is an IBM application development manager from Dallas in charge of the group that produced the CICS REXX product.

He stated that 81% of the world's business transactions (on all platforms) are done under CICS on MVS or VSE. One of his motivations for producing CICS REXX was that he was expecting many VM customers to migrate to MVS, where they would wish to use their REXX expertise (and EXECs). IBM had received hundreds of customer requirements for REXX under CICS.

His first goal was to develop a strong productivity tool. The TSO/E REXX kernel served as the base for the interpreter. Added to that were REXX language support for CICS, a REXX-DB2 interface, and a native CICS application environment, including a text editor (with XEDIT and ISPF personalities), an interactive shell, a panel facility, a VSAM-based REXX file system, and file system utilities. The programmers in his group (mostly COBOL CICS programmers) have been amazed at their own productivity gains from using REXX. They believe that this gain has been on the order of 10-20 fold.

Vogel referred to a REXX CICS user experiences session presented at SHARE by Steve Ware, of the University of Florida.

Dick Goran (CFS Nevada, Inc.), "REXX Changes in OS/2 Warp Version 3"

(Back to Table of Contents; on to next session).

Goran is the author of the highly-recommended REXX Reference Summary Handbook and writes a REXX column for OS/2 Magazine.

I am too ignorant of OS/2 to attempt to reproduce his excellent talk; I suspect much of it will be found in forthcoming columns. His theme seems to have been taken from a line in his June, 1995, column:

The developers did a much better job designing the LaunchPad than the chroniclers did documenting it, as is typical of so many things in OS/2.
His talk revolved around determining how five new REXX functions added in Warp really work. The functions are SysCopyObject(), SysMoveObject(), SysCreateShadow(), SysSaveObject(), and SysOpenObject(). Fully understanding these new functions required lots of experimentation and help from his friends, because much that one needs to know is not documented. The new Third Edition of Goran's Handbook (ISBN 0-9639854-2-6) discusses the Warp additions.

Goran maintains an FTP/Web directory for distributing many of his OS/2 utilities at http://ftp.cfsrexx.com

David Salthouse (Open Direct), "S/REXX for UNIX"

(Back to Table of Contents; on to next session).

Salthouse is a former IBMer who now heads a software marketing company based in France. Among his products are S/REXX and SEDIT, which are REXX and XEDIT implementations for UNIX (for most of the important UNIX platforms, including AIX, HPUX, SunOS, Solaris, SGI, LINUX, Ultrix, etc.). SEDIT has a GUI interface; S/REXX includes a Motif-based debugger. Both were written by Robert Benaroya.

Salthouse commented that there is very little market for REXX in the UNIX world so far, because "we are not very good at explaining why REXX is good". His company is trying to use other products, such as SEDIT, to gain access to a vertical market. They now have a considerable number of customers, both commercial and university.

S/REXX is REXX 4.0 with the exception that the numeric digit specification is limited to 15. It includes full EXECIO support to facilitate the porting of CMS applications. It adds several built-in functions for the UNIX environment: CWD(), CHDIR(), MKDIR(), RM(), GETENV(), etc. UNIX(cmd,stem) issues a UNIX command and retrieves the result in a stem. Assigning a UNIX command enclosed in backquotes to a variable causes the result of the command to be assigned to that variable. User-supplied built-in functions written in C are supported; ADDRESS environments may be set up to allow C programs to retrieve and set REXX variables. In conjunction with SEDIT, S/REXX allows the building of MOTIF or OpenLook dialog boxes, with input fields, toggles, and buttons.

Martin Misseyer (Free University of Amsterdam), "A REXX-based Stock Exchange Realtime Client-Server Environment"

(Back to Table of Contents; on to next session).

Misseyer is an Assistant Professor of Economics at the Vrije University in Amsterdam, where he teaches decision support systems. The University had long had a portfolio simulation system called TRANSPAS, which began on a PDP11 in 1981. A key feature of the system was a real-time link to the Amsterdam Stock Exchange. The program was used to teach students about simulations and was also used by faculty members doing research, although the latter were in need of a more powerful database capability.

The simulation system, which was based on flat files and which was written in C, had evolved extensively over the years. In 1992, they lost the system it was running on (an IBM RT) and were left with tens of thousands of lines of C code that they decided would be too costly to port. (They did not have sufficient C experience, and they wanted a more sophisticated environment. The old program would also have required considerable reworking because the Stock Exchange had introduced a new trading system with a very different interface.)

A decision was made to move the system to SARA's VM system, rather than to a Sparc, and to do much of the reprogramming in REXX. On the VM system, they could set up a relational database containing all their data from the Stock Exchange and use it for both historical analysis and real-time simulation. After the rewrite was well under way, it was learned that the VM system would be terminated at the end of 1995, so the project is being moved to multiple platforms, including AIX and OS/2.

The client/server interface to SQL/DS that they had developed in REXX was ported to DB2/6000. OS/2 REXX programs were written perform the X.25 communications. They were able to port much of the code they had already developed on VM; in fact, they were able to move to the new platforms in only a few days. They found themselves using REXX for:

  • Systems and communications applications,
  • Integration of non-REXX applications into the system,
  • User area applications,
  • Environment monitoring tools (written mainly in VX-REXX), and
  • Interfacing to FTP, SQL, C, and X.25.

They are now working on a second generation of their simulation program using VX-REXX-based client/server function. Their future projects include a data extraction tool and a WWW server for the Stock Exchange with real-time graphical displays of the Stock Exchange index.

Misseyer's conclusions were:

  • REXX is usable in a critical real-time environment.
  • REXX has a substantial number of interfaces.
  • REXX performs well.
  • REXX is successful in a multi-platform environment and is portable between platforms.
  • REXX is suitable as an application development tool for use in research and education.

He would like to see:

  • Better file sharing,
  • Better performance, and
  • More REXX-based tools.

He recommended that portability issues be well understood during the design phase of any application that is likely to be ported between platforms.

Lois White (SLAC), "REXX and How I Hit the Ground Running in UNIX"

(Back to Table of Contents; on to next session).

Lois White, a long-time SLAC staffer (and long-time user of REXX), subtitled her talk "How I Learned to Stop Worrying and Love to Type in Significant Mixed Case".

Lois's primary responsibility is analysis of utilization and performance of SLAC's computers. Thus, she has had to make the move from VM to UNIX over the past few years. Since REXX has been her language of choice since the early Eighties, she was glad to find that most of her UNIX work could be done using Uni-REXX. (She finds the shells too weak and Perl too cryptic; a high priority is placed on producing readable code.) She has been using Uni-REXX since early in 1993 and recommends the Uni-REXX manuals as being particularly good for people making the transition from CMS to UNIX.

Lois was able to port her analysis skills readily. UNIX accounting data provided the information she needed, but there were no suitable reporting tools. She has developed what she needs, however, by using a combination of crontab entries, REXX, and SAS. With these, she has built a system to collect data, store them, produce (very handsome) reports, and do directory cleanup. She was able to port "lots of code" directly from CMS to UNIX. She is using the same techniques to analyze utilization of their network and telephone system.

RexxLA, The REXX Language Association

(Back to Table of Contents; on to next session).

The REXX Language Association is an independent organization dedicated to promoting the use of the REXX programming language. Membership information can be obtained from:

Membership benefits include a subscription to the Association's quarterly newsletter and a discount on REXX Symposium registration.

Attendee Announcements and Other Notes

(Back to Table of Contents).

Perhaps the best quip of the week was a reference to Perl as being "REXX done using only special characters".

Proceedings of the REXX Symposium are free of charge and can be ordered by sending email (including your postal address) to techpub@slac.stanford.edu. The Proceedings from the 1994 Symposium are still available; ask for SLAC Report 447.

Gabe Goldberg, co-editor of The REXX Handbook (Gabe Goldberg and Phil Smith III, eds., McGraw Hill, 1991, ISBN 0-07-023682-8), is thinking of putting together a REXX supplement for the Enterprise Systems Journal. (Gabe has been involved with earlier supplements.) His first task is lining up advertisers to fund the project; then he will recruit authors to write articles. He would like to hear from anyone interested in participating in this project. He may be reached at:

  • Gabe Goldberg
    7718 Iroquois Court
    Falls Church, Virginia 22043
    (703) 556-9121
    gabe@cpcug.org

Another highly recommended new REXX book emphasizing OS/2 is The REXX Cookbook, available from:

  • Whitestone
    511-A Girard Boulevard SE
    Albuquerque, New Mexico 87106
    (505) 268-0678
    5979987@mcimail.com
The ISBN for the book is 0-9632773-4-0 and for the book with a companion diskette, 0-9632773-6-7.

Printing the Proposed ANSI Standard from CMS

I had considerable difficulty getting the PostScript file containing the proposed standard to print on CMS. It is rather oddly blocked (line end is indicated in some places by CR, in others by LF, and in others by CRLF), and the twelve segments are surrounded by PMPub (whatever that is) controls. I was successful in printing the document after uploading it in binary mode and running it through the following CMS EXEC and REXX CMS Pipelines filter to generate separate PostScript files for the twelve segments:

/* FIXJ18 EXEC */

'PIPE (name FixJ18Pub)',         /* Make J18PUB CMS printable.  */
  '< j18pub binps |',            /* Read binary PostScript.     */
  'xlate a2e  21 5a  5b ad  5d bd  7c 4f', /* Make it EBCDIC.   */
             'a2 4a  a8 bb  ac b0  dd ba |',
  'deblock crlf |',              /* Deblock.                    */
  'split at anyof x0D25 |',      /* Deblock some more.          */
  'putj18'                       /* Break up into segments.     */

/* PUTJ18 REXX:   Break off pieces of J18PUB  */

Signal On Error

Do n = 1 by 1                    /* Do until end-of-file.       */

  'PEEKTO'                       /* Exit at end-of-file.        */

  'CALLPIPE (name PutJ18)',      /* Break off segment of file.  */
    '*: |',                      /* Input from calling pipe.    */
    'drop first 1 |',            /* Discard "userdict /PMpub".  */
    'tolabel userdict /PMpub|',  /* Up to the next segment.     */
    'drop last 1 |',             /* Discard "PMpub` restore".   */
    '> j18pub ps'n 'a'           /* Write this piece to disk.   */

End

Error: Exit RC*(RC<>12)          /* RC = 0 if end-of-file.      */


Melinda Varian / Office of Computing and Information Technology / Princeton University / maint@pucc.princeton.edu